Protecting resources in a distributed computer system

ABSTRACT

This invention concerns methods for the protection of resources in an open digital communication system, which resources are residing in or owned by physically and organizationally distributed, independent entities connected through that system, e.g. the Internet. Since, in such an open system, any entity can in principle access any resource of any other entity, precautions must be taken to avoid or minimize the danger of resource corruption and destruction, to maintain privacy and, where necessary, confidentiality. Thus, protection of resources is of ultimate importance to warrant integrity and function of an entity. For the intelligent protection of such resources, in particular against unauthorized access, a variable-grained control of the name space (consisting of all names an entity provides) and/or the provision of attachable and detachable guards accompanying each call for a file and/or service is provided.

FIELD OF THE INVENTION

In an open digital communication system connecting physically andorganisationally distributed, independent entities, this invention isrelated to methods for the protection of resources residing in or ownedby these entities. Since, in such an open system, any entity can inprinciple access any resource of any other entity, protection ofresources is of ultimate importance to warrant integrity and function ofan entity. A current example for such a system is the Internet with itsdistributed processing stations, servers and end-user computers, whichprovide and own the resources, e.g. data or program files. The presentinvention concerns the intelligent protection of such resources, inparticular against unauthorized access.

BACKGROUND AND PRIOR ART

Resource sharing is a well-known concept in many areas: by sharing ascarce, expensive, or seldom used resource, the burden of maintainingthis resource is distributed among a group of users. Hand in hand withthe desire to share a resource goes the desire to protect the resourcefrom unauthorized use: Resource sharing usually implies resourceprotection. Not surprisingly, resource sharing and resource protectionare key issues of distributed, networked computers. The more computersbecome ubiquitous and connected, the more the need arises to have meansof protecting resources in these connected systems. This requirement isespecially true for open networks like the Internet. In such an open,distributed, networked system, it is unavoidable to protect specificresources from unauthorized access, such as sensitive data like passwordfiles and private materials, or hardware resources like file systemspace and communication capacity, or services like cryptographicservices. Protecting here means both the basic access to the resourceitself and the use of it by an accessing entity; that is, bothcoarse-grained resource protection (e.g. an entity is allowed to usefile system services) and fine-grained resource protection (e.g. anentity is allowed to use file system services, but cannot accesspassword files).

Current approaches to resource protection in distributed systems rely inmost cases on authentication-based schemes that require more or lessextensive changes at the service- providing entity. “Kerberos” forexample, as described by J. G. Steiner, B. C. Neuman, and J. I. Schillerin “Kerberos: An authentication service for open network systems” inUsenix Conference Proceedings, Usenix, February 1988, requires encryptedtickets to be sent along with each service request. After havingauthenticated herself/himself with a special and trusted ticket grantingservice, the user can request Kerberos tickets for any other servicehe/she is entitled to use and wants to invoke. Though rather safe, thisis a burdensome, time-consuming, and traffic-increasing way to achievethe desired goal of resource protection. More specifically, the Kerberosapproach to resource protection suffers from the drawbacks both that itis not transparent (in the sense that it visible) to theservice-providing entities and that it is a discretionary mechanism inthe sense that the called entity itself has to check explicitly for avalid ticket from the calling entity. The code implementing the entitymust contain calls to respective libraries; an entity that “forgets” tocheck for a valid ticket will provide access to its resource to anycaller. Furthermore, once an attacker compromises the central ticketgranting service, he/she also has access to all entities thatparticipate in the associated distributed system.

Another solution for the resource protection task was presented by D. B.Clifton in U.S. Pat. No. 5,469,556, entitled “Resource access securitysystem for controlling access to resources of a data processing system”,issued November 1995. Clifton introduces special objects, so-calleddescriptors, for addressing resources such as memory addresses inhardware. Attached to each descriptor is a set of tables that controlsaccess to a particular resource. Essentially, this descriptor forms avirtual address of the resource (cf. column 3, lines 34-37 of theClifton patent), and as such establishes a fine-grained access controlfor resources in a system.

Although Clifton's approach to resource protection does not suffer fromthe central vulnerability as Kerberos does, this immunity alsorepresents one of its disadvantages. Clifton's approach is notapplicable to distributed systems as it is tied to the memory addresstranslation mechanism—and thus to a single address space—through the useof its descriptors. A distributed system, however, practically bydefinition comprises several address spaces connected by some kind ofcommunication medium. In addition, Clifton's solution is also nottransparent, the user must use the special descriptors and thus has tocode his/her programs accordingly.

Furthermore, both the Kerberos and the Clifton approaches cannot dealwith resources that appear dynamically during the runtime of the system(and after the resource protection mechanism has been set up). In anenvironment where entities can immigrate into a distributed system fromthe outside (e.g. a Java applet coming in from the Internet) existdynamically created resources and it is necessary to offer protectionfor these resources, too.

Thus, it is the main object of the invention to establish a resourceprotection mechanism that is applicable to dynamic distributed systems.A further object is to create a resource protection mechanism that istransparent to a program and/or entity that wants to access theresources to be protected. A still further object of the invention is todevise a method for resource protection that is dynamically expandable,preferably during runtime, to protect newly created resources.

SUMMARY OF THE INVENTION

Resources to be protected against unauthorized access in a distributedsystem are usually owned or provided by entities, e.g. servers or otherprocessing stations. Although, in principle, in an open, distributedsystem, each entity is allowed to access any resource of any otherentity, as discussed above, security requires to protect certainresources and to allow access to them only for certain entities and/orunder certain conditions.

Resources may be disk space, files, network connections, but alsomethods offered by objects and objects themselves. Access to suchresources in a distributed system occurs through services or methods,provided by entities or objects. The inventive concept starts from theidea to reduce the access to a resource to the access to a service. Toinvoke or use a service, the names of both the entity owning orproviding the service and of the service itself must be known. Toactually access a service, a mapping of its name to its location isobtained, i.e. the name is resolved. The total of the names that anentity “knows” form the name space of that entity; similarly, the totalof the entity locations of a system constitute the entity location spaceof that system.

The underlying basic concept of the invention thus consists incontrolling an entity's access to a service by controlling the nameresolution process, e.g. by limiting the visibility of services for thisentity. A further feature of the invention consists in providing avariable-grained control of the name space and of the name resolutionprocess, e.g. by executing this control by an “intelligent” interceptionmanager. An independent main feature of the invention consists inproviding attachable and detachable “guards” which are associated with aname and called before or after this name is used and provide forfine-grained resource protection.

By using one or more of the features above, a dynamically configurableprotection domain is created, meaning a controlled and confinedenvironment, i.e. a dynamically configurable “sandbox”, in whichentities can operate freely. Effects of any malicious behavior arerestricted to the sandbox and thus cannot propagate to the rest of thesystem. One can also provide tightly controlled entry and exit points toand from such a sandbox, and, in particular, fine-tune its shape andsize dynamically.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 shows an entity with its interfaces and resources (terms definedbelow);

FIGS. 2a, 2 b depict ways of mapping a name and its object objectreference;

FIGS. 3a-3 c exhibit steps and variations of the method according to theinvention;

FIG. 4 is a block diagram of an implementation of the invention.

DESCRIPTION OF A PREFERRED EMBODIMENT

In the following, a general overview (A) of the features of theinvention will be first given, followed by description of animplementation of the invention (B), both in the environment of aJava-based network as an example for an object-based, distributed,networked system. Java is a programming language and environmentdeveloped by Sun Microsystems, Inc. 2550 Garcia Ave., Mountain View,Calif. 94043-1100, USA; the term “Java” is a trademark of this company.

A. Overview of Principles

The Java Environment

In the following, some typical terms relating to the Java computingenvironment and used in this description shall be listed and brieflyexplained.

An applet is Java bytecode which is typically is loaded from a remotesource; it is usually not considered trustworthy.

An application is Java bytecode which is typically loaded from local; itis usually considered trustworthy.

The Internet is a worldwide, open computer network consisting of manydifferent subnetworks.

The World Wide Web (WWW) is an open subnetwork of the Internet.

An intranet is a closed internal network, usually a subnetwork of theInternet, often used within companies.

A browser is a computer software or environment supporting the lookingaround (surfing) in the World Wide Web and for downloading and executingapplets.

Java bytecode is code produced by a compiler for the JVM, see below.

The Java Virtual Machine (JVM) is a fictional, but well-specifiedprocessor which executes the Java bytecode. It is fictional because themachine is implemented in software.

A library is a collection of defined functions or classes for use in aprogram.

A sandbox is a playground to which Java applets are confined. It is anexecution environment delineated by borders with defined entry and exitpoints (gates), see below.

The Sandbox Security Model

The so-called sandbox, described by J. S. Fritzinger and M. Mueller in:“Java Security”, Sun Microsystems, Inc., 1996, supra, dedicates a“playground” delineated by defined borders and gates to Java applets.All applets are confined to this sandbox. In order to access somethingoutside the sandbox, an applet must pass through a corresponding gate.Similarly, any communication with the applet has to go through thegates, which control and may restrict the crossing. Typically, appletsare developed remotely. A user customarily initiates the downloading ofan applet and it usually travels over untrusted public networks such asthe Internet.

Whether an applet can be trusted or not depends essentially on thefollowing factors:

Can an applet programmer be prevented from writing hostile programs,i.e. can the programmer be trusted?

Can the compiler which produces the bytecode according to rules definedby the language specification be trusted?

Can the network be trusted, where an intruder might damage or modify theintegrity of the applets?

Any applet suffering from any of the above is not consideredtrustworthy. Stand-alone applications on the other hand are typicallydeveloped locally, i.e. in a secure environment, or travel over trustednetworks such as an intranet. Therefore, applications are usuallyconsidered trustworthy. However, this coarse black and white distinctionbetween applets and applications is not sufficient. Since the sandboxapproach is applied to applets only and not to applications, theimplemented security is limited to applets. In addition, numerous bugshave been discovered in the implementation of presently known sandboxeswhich renders its available implementations insufficient and incomplete.

Usually, the sandbox is implemented in the browser. It is hard-codedwith no enduser interaction possibility and is not programmable. It istherefore a static model with fixed borders and fixed gates. Only thedecision of a gate varies, not the gate itself, i.e. its location, itspolicy, or its existence. This model does not consider the origin ofdownloaded code; it only coarsely distinguishes between local and remoteprograms, i.e. applications and applets.

In short, the known implementation of the Java security model fails toseparate the enforcement of an appropriate security policy and themechanisms that implement the policy. The known security model isstatic, and its implementation of the sandbox paradigm is insufficientas most user-controlled decisions are hard-coded in the Java VirtualMachine. Obviously, the lack of configurable security features limitsthe acceptance and applicability of this known security model.

The new security mechanism for object-oriented systems according to theinvention can be directly applied to the Java environment. Whereas someof the terms essential for this chapter have well-accepted definitions,others are used in a specific way in this description. For consistency,a short definition of those terms follows.

Terminology

Objects encapsulate data and provide methods; the data can be accessedonly through these methods. Objects are created dynamically, that is,they are instantiated.

Classes are definitions for objects and are static.

Entities are considered as objects or referenced classes, regardless ofwhether they are active or passive; entities own or provide resources.

An interface consists of a set of methods of an entity through which theentity data and services can be accessed and transformed.

A name is a symbolic reference to a method of an entity; a name is NOTunderstood. i.e. interpretable, by the execution component of theruntime system.

An object reference is a pointer to a location of a method of an entity;an object reference is understood, i.e. interpretable, by the executionenvironment of the runtime system.

A service is considered a method of an entity, either referenced throughan object reference or through a symbolic reference.

The Invention

The novel security mechanism is aimed at protecting resources againstunauthorized access in an object-oriented system. It can be used forauditing and monitoring resource usage as well as for access control.The design of it is based on the basic assumption that no program can doany harm if resource access is strictly controlled. The followingcomponents, alone or in combination, appear essential to the securitymechanism according to the invention:

Object-oriented paradigm: Data are encapsulated by entities and can betransformed by provided interfaces only. The approach to protect theentities data is to control access to their interfaces.

Lazy object binding: Each symbolic reference (or name) is substituted atruntime by the corresponding object reference, through which the servicemay be invoked. This substitution process is intercepted by the securitymechanism according to the invention.

Name resolution: To obtain an object reference for a given name (asymbolic reference), a name resolution is necessary. This nameresolution maps the name to an object reference. In the novel mechanism,this mapping may be intercepted by an interception manager whichcontrols the name resolution.

Guard object: They can be attached arbitrarily to object references.These guards are invoked before and/or after the object reference isused. In addition, they may access context information.

The Object Oriented Paradigm

Resources are encapsulated by entities and can be accessed only throughprovided interfaces. Thus, in order to protect resources in anobject-oriented system against unauthorized access, one can reduce theissue of controlled access to such resources to the problem ofcontrolling access to the interfaces of the associated entity. An entitymay provide different resources, and therefore, provide differentinterfaces, as shown in FIG. 1. To use a particular resource, the name(and the location) of this resource must be known; this name is thentransformed into an object reference, which points to a location, wherethe corresponding method resides.

Lazy Object Binding

Binding is the process of linking necessary components of an executablecode together. The components are produced by the compiler and arecalled object files. Object files contain symbolic references to otherobject files. By linking these object files together, a linkersubstitutes symbolic references with a corresponding object reference.At that point, the executable code possesses the necessary objectreference, that is standable, i.e. interpretable, by the executionenvironment, and thus the executable code is able to invoke thereferenced methods.

If the substitution is done at runtime, it is called dynamic bindingotherwise, i.e. if the substitution is done before the code is executed,it is static binding. If the substitution of all symbolic referenceshappens at one point in time, the link process is called eager binding.In case it is done only once an object reference for a symbolic name isneeded at runtime, it is called lazy binding. Once the substitution isdone in the executable code, it is fixed and is not subject to changeanymore.

A C++ compiler, for instance, merges the human readable, symbolicallyreferenced methods of other entities (i.e. names) with their typeinformation into further symbolic references. Any of these references isstill symbolic (i.e. a name), but not in human readable format anymore.The binder then includes the appropriate code, according to the symbolicreferences, and substitutes the symbolic references with an appropriateobject reference. This object reference then points to the beginning ofthe location where the method resides. The Java environment uses a lazybinding approach. Each symbolic reference is substituted once theexecution environment uses it.

The distributed approach allows the invocation of methods across addressspaces and/or systems. In most cases, remote objects are represented byproxy objects which act as their local representatives. Usually, proxyobjects locate, create, destroy and invoke the remote object. Thus, theobject reference points to the location of the corresponding proxyobject.

Interception and Name Resolution

A particular feature of the novel mechanism intercepts the bindingprocess, whether it is an eager binding or a lazy binding scheme, andinterposes an interception manager. The resolution of the symbolicreference, i.e. the name, requires a mapping between the latter and thecorresponding object reference. The process of finding the correspondingobject reference to a given symbolic reference (name) is the nameresolution. This is executed by a name resolution process as shown inFIGS. 2a and 2 b. To use a particular method, the calling entity has toknow the symbolic reference or name which must be properly resolved toan object reference. The separation of references the entity might knowof, which are represented by their symbolic references, and thereferences the entity certainly knows of, which are represented by theirobject references, leads to two different name spaces:

The presumed name space of an entity consists of a set of symbolicreferences. These symbolic names are not yet resolved, but arecandidates for the resolving process. Entities presume that thesereferences exist, but these presumptions have not yet been verifiedthrough the resolving process. These methods can not yet be invoked;they are not understandable by the runtime execution component.

The concrete name space of an entity consists of a set of objectreferences. These object references are resolved names, which aredefinitely known by the entity because they have been verified by theresolving process. Object references are understandable by the runtimeexecution environment.

The set of methods referenced in the concrete name space is usually asubset of the methods referenced in the presumed name space. Thereferences are different (object reference vs. symbolic reference), butthe referenced method is the same.

Interception Manager

The so-called interception manager shown in FIG. 2b is an optionalfeature of the invention. The main responsibility of the interceptionmanager, if provided, is to control and modify the name resolutionprocess according to a particular security policy. For example, it cantighten the concrete name space by preventing the resolution of somesymbolic name. To intercept the name resolution process and interposethe interception manager leads to an access control mechanism. Thisregulation of the concrete name space for security purposes is based onthe assumption that no resource can be used without having the objectreference of its representing entity. A symbolically referenced methodis resolved, if and only if the interception manager allows thisresolution.

As shown in FIG. 2b, the interception manager is part of the nameresolution process. The result of the name resolution process, an objectreference, is intercepted; the interception manager either returns theunmodified object reference or an object reference attached with guardobjects or an exception that the referenced entity does not exist. Thegranularity of access control performed by the interception managerdepends on the granularity of the resolution process. More precisely,the interception manager may act on a coarser level but not on a finerlevel. Nevertheless, variable-grained access control is still existing.The interception manager has access to context sensitive information,such as the source entity name, the destination entity name, and theirdata. To control access alone may not be sufficient in some cases and itmay be necessary to monitor or to audit resource usage. This demands afurther component of the security mechanism to be invoked before and/orafter the protected resource is used. Such an object is called a guardwhich can be inserted by the interception manager.

Guard Objects

Guard objects, another optional feature of the invention, are associatedwith a particular object reference and will be called before and/orafter that object reference is used, depending on how the interceptionmanager installed the guard objects.

A guard object is said to be installed before the destination entity, ifthe guard object is invoked before the associated object reference isused, and thus has access to the supplied arguments for the destinationentity. A guard object is said to be installed after the destinationentity, if the guard object is invoked after the associated objectreference is used, that is, the called method returns, and thus hasaccess to its return value. FIG. 2b shows the modified object referencewith attached guard objects as one of the return results of theintercepted name resolution process.

If the guard object indicates no error, execution continues as usual.Similar to the context information used by the interception manager,guard objects also have access to context sensitive information. Thisincludes the source entity name, the destination entity name, andinvocation parameter(s). If guard objects are installed before thedestination entity, they may perform the following actions:

reject the invocation

pass the invocation unchanged

transform the invocation supplied data

change the destination of the invocation

assign and/or check rights to the caller entity

monitor the access

perform a notification and/or auditing service.

If guard objects are installed after the destination entity, they mayperform the following actions:

change return parameters or state

remove previously assigned rights

monitor the reply

perform a notification and/or auditing service.

Guard objects cannot be influenced by the source or destination, i.e.calling and called, entity, because they have been attached from outsideby the interception manager.

Guard objects are invisible, transparent, as far as the invoking and theinvoked, i.e. calling and called, entities are concerned. Contrary tothe interception manager, guard objects are unable to tighten theconcrete name space directly, they may influence it indirectly, though:They are able to unresolve the object reference to which they areattached to the original symbolic reference. As a consequence of thisunresolving, the next usage of this method shall again encounter asymbolic reference, and shall lead to a call to name resolution and,therefore, to the interception manager. The interception manager thenhas again the possibility of modifying the concrete name space of thecalling entity according to its security policy. Object referenceunresolving might be useful if the security policy changes after thesymbolic reference has been resolved.

In addition, each guard object has the possibility to decide how long itwants to be attached to its object reference. A guard object may decideto detach itself, and therefore will not be called any longer for theinvocation of the object reference.

Capabilities

A so-called capability is the right to invoke a particular object in aparticular mode (explained further down in the description). Asdescribed by A. S. Tanenbaum in “Modern Operating System”, Prentice HallInternational, Inc., 1995, the right may include three components:

(1) A pointer to the object: The required pointer is accomplished by theresolved reference—the object reference. It is assumed, that a properruntime system makes the invocation possible, if an executable code hasthe pointer. That means that every entity that possesses a capability isable to invoke the corresponding method.

(2) The type information of the object: The required type information isaccomplished through attached guard object(s). The type of thecapability depends on the associated guard object(s).

(3) An access right for the object: The required access right isaccomplished by attached guard object(s). They may check the rights, thecalling entity must provide to use a particular method. In addition, ifthe calling entity has the appropriate rights, the guard object mayenhance existing rights, or may assign new rights, to use this service.

Guard objects together with the object reference are similar to acapability, but are not the same. A resolved name with an installedguard object may be considered as an enhanced dynamic capability. Thedynamic component of a capability is the associated guard object.

Overview Summary

The presented approach for protecting resources in an object-orientedsystem thus includes one or more of the following features: Theobject-oriented paradigm lends itself well to control access toresources through objects and their interfaces. Access control isachieved through control of the name space for the calling entity, thuscontrolling the visibility of resolved names. If the calling entity isunable to see a service, it cannot invoke it; without invocationpossibility of a method, the associated resource cannot be used. Sincethe resolution manager (and the optional guard objects) may use contextinformation, they may act very flexible and context dependent. Guardobjects can be attached from outside, without the knowledge of eitherentity; they are invisible, transparent as far as the calling and thecalled entity are concerned. Thus, the mechanism protects with littlecosts in terms of performance overhead and in a dynamic fashion.

B. Implementation

In the following, an implementation of the security mechanism accordingto the invention is described in the Java environment. All changes madeto the Java Virtual Machine (JVM) which includes the interpreter and theruntime library will be reviewed. In addition, the components of theinvented security mechanism which are implemented in Java shall also bepresented.

Since this chapter also deals with details of the implementation, theperson skilled in the art is assumed to be familiar with the basicmechanisms of the JVM and its implementation in the C language as wellas the Java programming language itself. A comprehensive presentation ofthe Java language and its implementation of the JVM was disclosed by J.Goslin, B. Joy, and G. Tele in “The Java Language Specification” and T.Lindholm and F. Yellin in “The Java Virtual machine Specification”, bothby Addison-Wesley Publishing Co., 1996. The implemented components ofthe invented security mechanism are based on the Java Development Kit(JDK) Version 1.0.2 and the AIX Version of the JVM. This chapterdescribes the components of protecting system resources represented bysystem classes. The changes to the Java Virtual Machine were kept assmall as possible, a few changes were unavoidable, though.

B1. Functionality Overview

The implemented functionality of the invented security mechanismcomprises an implementation of an interception manager and somerudimentary guard objects. The term entity is refined from the previouschapter to apply to particular classes. A class is an entity in thesense that it owns and represents resources. Since system resources arerepresented through their corresponding system classes in the Javalibrary, the classes are well-known with an unambiguous, fully qualifiedname. Thus, this implementation provides protection of system classesthat reside in the Java library. An object reference received from thename resolution process (see below) is a pointer to the correspondingpiece of code, which actually points to the beginning of a methoddescription. Thus, the object reference includes the knowledge of thelocation, and the method can be invoked immediately.

Protection of system classes is achieved through controlling access tothem by modifying the name space accordingly. If the object's concretename space contains an object reference, subsequent access to thereferenced method is granted. Hence, as stated in the assumption above,the program can only access those resources for which the objectreference is available. To control and modify the concrete name space ofan object, the lazy binding mechanism and the name resolution areexploited by interposing an interception manager as discussed. Guardobjects are associated with object references. To call guard objectsbefore the original method is executed, the method invocation scheme isenlarged with a check for installed guard objects. To implement thisfunctionality, the following issues are crucial:

Resource protection through control of the name space

Changes in the method invocation component in the Java Virtual Machine

Interception information base class providing access to the native Ccode

Implementation of the interception manager

Guard object base class

B2. Java Virtual Machine Changes—System Level

This section discusses the enhancements of the Java Virtual Machine andthe Java runtime library. The enhancements are implemented in native Ccode and are thus machine dependent. The following components werechanged to implement the security mechanism according to the invention:

Name resolving component of the virtual machine

All opcodes dealing with method invocation

Binary method representation in memory

Thread structure

Name Space Modification

In order to achieve access control, and thus resource protection, theconcrete name space of the calling object is controlled; it is eithertightened or enlarged.

To modify the name space of the originating object, Java's lazy objectbinding method is exploited. Java's binary file layout references othersclasses and interfaces and their fields, methods, and constructorssymbolically, using fully qualified names. For fields and methods, thesesymbolic references include the name of the class or interface type thatdeclares the field or method, as well as the name of the field or methoditself, together with appropriate type information. Before an object canbe used, its name must be resolved to an object reference: Theidentifier is checked to be correct and, typically, replaced with adirect object reference that can be more efficiently processed if thereference is used repeatedly. If an error occurs, an exception will bethrown, see J. Goslin, B. Joy, and G. Tele in “The Java LanguageSpecification” and T. Lindholm and F. Yellin in “The Java Virtualmachine Specification”, both by Addison-Wesley Publishing Co., 1996.

After the name is resolved to an object reference, the interceptionmanager is called which decides whether resolution of the symbolicreference should be permitted (see FIG. 4). Thus, the name resolution isintercepted, and therefore the lazy object binding. According to thereturn value of the interception manager, the concrete name spacemodification is performed:

If the interception manager returns false, a NoClassDefFoundErrorexception is thrown, indicating to the invoking object that the classfile is not existent. Therefore, the name of the desired resource cannotbe resolved and, as a consequence, the location of the correspondingpiece of code is unknown. This scheme of asking the interception managerand subsequently throwing an exception tightens the concrete name spaceof the calling object.

If the interception manager returns true, the invocation continues asusual and the concrete name space is not modified. In fact, the concretename space is enlarged with the resolved name, that is, with a pointerto the corresponding piece of code, with the object reference.

Code fragment C1 below depicts the new code that was inserted in thename resolution function. This C code fragment performs the followingsteps:

(1) Initializes the structures needed for managing guard objects.

(2) Checks whether the requested resolution is allowed; if not, mark themethod as unresolved and return false.

(3) Otherwise mark the method as resolved and replace the symbolicinformation with a pointer to the corresponding piece of code.

Since the interception manager may attach several guard objects, themethod invocation scheme required modification, in addition to the nameresolution process.

Code Fragment C1

This code fragment has been inserted in the function which resolvessymbolically referenced names. The appropriate exception is thrown inthe ic₁₃ CheckMethod Resolving( ) method. (In this code, guard objectsare called “filter objects”.)

[resolving method] /* * If the corresponding method representation *could be found, prepare the filter dispatch * table for this method */ic_PrepareFilter(class, mb); /* * Now check whether this particularname * resolving is allowed or not */ if (!ic_CheckMethodResolving(mb)){ /* * Ooops, no permission to resolve this method * mark it unresolved,therefore */ fieldfiltertable (&mb->fb)->resolved = FALSE; return FALSE;} /* * Mark the method as resolved */fieldfiltertable(&mb->fb)->resolved = TRUE; /* change the symbolic nameinformation to * a pointer to the appropriate methodblock */constant-pool[index].p = mb; continue_as_usual ( ); [ . . . ]

Method Invocation

The Java interpreter is responsible for executing methods that have beenresolved already. A detailed discussion about the method invocationrelated procedures was described by T. Lindholm and F. Yellin in “TheJava Virtual Machine Specification”, Addison Wesley Publishing Co.,1996. FIG. 4 outlines the control flow of a method invocation. The tennew components added by the invention are 19-25 and 27-29, the othercomponents are original Java components. The new components according tothe invention include checks concerning name resolving and execution ofguard objects.

Opcodes

An opcode is a short term, usually a number, representing a particularset of operations. It represents a particular functionality. Forexample, the opcode 182 (0xb6), associated with the mnemonicopc_invokevirtual, represents the basic steps to invoke a virtualmethod. A detailed description of the various Java opcodes and thefunctionality they provide can be found in T. Lindholm et al, supra. Toinstall and maintain guard objects, the implementation of opcodesdealing with method invocation is changed. The functionality is extendedwith a check for guard objects and with code to execute themsubsequently. After the last guard object is executed, the originalmethod is executed.

C2 is a C code fragment that has been inserted in every opcode dealingwith method invocation. This code fragment performs the following steps:

(1) Check whether there have been guard objects installed or not; if noguard objects have been installed continue as usual.

(2) Check whether the method is resolved or not; if it is resolved,subsequently call the installed guard objects.

(3) Check whether an exception has to be handled or not; if an exceptionhas been thrown, abort the execution of methods and handle it.

To attach guard objects to object references, the memory layout of theoriginal method is extended.

Code Fragment C2

This code fragment is inserted before execution of the original method.

[execute method] /* * filter dispatch table installed? * if yes, checkwhether there are * any filter objects installed or not? */ if(fieldfiltertable(&mb->fb) && (fieldfiltertable(&mb->fb)->used_filter)){ /* * method resolved through the invention mechanism? */ if(fieldfiltertable(&mb->fb)->resolved == TRUE) { /* * invoke theinstalled filter objects */ic_InvokeFilterObjects(fieldfiltertable(&mb->fb), ee); } else { /* *check the name space, therefore invoke the * InterceptionManager object*/ ic_CheckMethodResolving(mb); } /* * everything ok? nobody threw anexception */ if (exceptionOccurred(ee)) goto handle_exception; }continue_executing_original_method( ); [ . . . ]

Method Representation

To execute an arbitrary method of an object, the method needs acorresponding binary representation in memory. The binary representationof a method is split into static components and dynamic components. Thestatic components include its class description and static fields, thedynamic components include its dynamic fields. The distinction betweenthe text and data segments in the representation of the binaryexecutable in the UNIX operating system is a similar concept; bothsegments are mapped into different areas of the address space—the textsegment is mapped in read-only mode and the data segment is mapped inread/write mode.

The static components of a method are shared by all objects instantiatedfrom the same class description, but each object has its own dynamiccomponents. Guard objects are attached to a static component of amethod, the fieldblock structure. Thus, a guard object is also shared byall instances of the same class description. Although guard objects areattached to the static component, the implementation is prepared toattach guard objects to distinct objects and their methods rather thanto classes and their methods.

Guard Dispatch Table

The guard dispatch table manages attached guard objects. It holds thereferences of each guard object and indicates how many guard objects areinstalled. The header consists of the following administrative elements.(For historical reasons, guard objects are called “filter objects” inthe code):

a variable indicating how many guard objects are used (denoted byused_filter)

a variable indicating the number of guard objects for which space isallocated (denoted by res_filter), where res_filter>used_filter must betrue at all times

a flag indicating whether the method is considered resolved or not(denoted by resolved)

a pointer referring to the attached method representation (denoted bymb)

a pointer to the class file of the calling object (denoted by caller)

a pointer to the first element of a dynamic array comprising the managedguard object structures.

The following code fragment C3 shows the structure of the guard dispatchtable header.

Code Fragment C3

This is the header of a guard dispatch table.

struct filterdtable { int used_filter; int res_filter; int resolved;struct methodblock *mb; struct ClassClass *caller; struct filterdesc*filters[1]; };

The type of element of the array, which is denoted by filters, is shownin code fragment C4; it comprises the following components:

a pointer to the object memory location of the guard object (denoted byobj),

the name of the method which should be called (denoted by methodname),

the corresponding signature, since it is possible to implement that twomethods have the same name but different signatures (denoted bysignature),

and a call-back methodname (denoted by notify) which specifies a methodat the interception manager class that is called when the guard objectsdetach themselves from the corresponding object.

Code Fragment C4

Each entry in a filter dispatch table is of the type filterdesc.

struct filterdesc { HObject *obj; char *signature; char *methodname;char *notify; };

Since the guard objects are implemented in Java, they are in turnpotential candidates for name space modifications and for attachingguard objects. To avoid a recursion problem, the executing thread ismarked accordingly.

Threads

A thread is an execution path in an address space. This address spacecan be shared by many concurrently executing threads. A detaileddiscussion about the thread concept was given by A. D. Birell in “AnIntroduction to Programming with Threads”, System Research Center (SRC)Report, Digital Equipment Corp., Jan. 6, 1989.

Guard objects and the interception manager according to the inventionare implemented in Java. Since they also access resources, a criteria isneeded to distinguish between components that belong to the mechanismaccording to the invention and components that do not. Otherwise, everytime the interception manager accesses a resource, and therefore invokesa method, it is checked by the interception manager itself. Thisrecursion is broken by appropriately marking a thread. If the threadenters a guard object or the interception manager, it is marked as athread being in a supervisor state. The next time it tries to enter aguard object or the interception manager, it is checked whether thethread is marked as being in a supervisor state. Depending on thepresence of this mark, the runtime system decides whether to subject thethread to the novel mechanism. If the thread leaves the guard objects orthe interception manager, the marker is erased.

This temporarily assigned status is somewhat similar to the traditionalUNIX system call concept where the process executing a system call hasmore rights for accessing resources than a process not executing asystem call. While in the kernel mode, a supervisor status is assignedtemporarily to the executing process. With these privileges, the processhas access to protected resources maintained by the operating system.When leaving the system call, the privilege status is erased. A detaileddescription of the system call concept was given by S. J. Leffler et alin “4.4 BSD UNIX Operating System”, Addison Wesley Publishing Co., 1996.

Guard objects and the interception manager also can access context dataand may modify them, including arguments supplied to the originalmethod. If the original method invocation is intercepted and theinterception manager is asked, or the guard objects are called, theexecuting thread is temporarily assigned a pointer to the stack frame ofthe original method. Hence, they have access to the method argumentssitting on the stack.

When entering the security components according to the invention, apointer to the appropriate guard dispatch table is assigned to theexecuting thread. Thus, the thread has complete access to all guardobjects.

To achieve the functionality described above, the thread structure isenlarged with the following components, which are all assigned to whenthe thread crosses the boundary between normal code and security code:

a single bit indicating whether the thread is in supervisor state or not(denoted by sv_thread)

a pointer to the appropriate guard dispatch table (denoted byiv_filtertable)

a pointer to the appropriate stack frame of the original method (denotedby ic_optop)

B3. Java Class Hierarchy—User Level

In this section, the components implemented in Java are discussed. Theimplementation of the novel security mechanism in Java follows one ofthe main principle of the Java philosophy: be as portable as possible.

Therefore, most of the implementation is done in Java using awell-defined interface to the components implemented in native C code.The routines implemented in native C code can be accessed through anabstract base class called InterceptionInfo.

Interception Information

InterceptionInfo is an abstract class in Java. It is used to provide thebasic security functionality according to the invention. A discussion ofthe class modifiers in Java was given by J. Goslin et al, supra. Thecomponents of this base class can roughly be divided into the followingcategories:

managing the installation of arbitrary guard objects

managing the removal of arbitrary guard objects

managing the order of installed guard objects

retrieval and modification of arbitrary arguments

retrieval of the fully qualified name of the calling object/entity andcalled object/entity, of the method name, and of the signature name.

An overview of the Application Programming Interface (API) provided bythe InterceptionInfo base class is given in the code fragment C5. Inorder to obtain full security functionality according to the invention,the interception manager class and all guard objects must subclass thisInterceptionInfo base class as shown.

Code Fragment C5

This class provides the interface for the implemented native C code.

public abstract class InterceptionInfo { protected native voidunresolveMethod( ); protected native int getIntArgument(int index)throws ArgumentAccessException; protected native void setIntArgument(intindex, int value) throws ArgumentAccessException; protected native floatgetFloatArgument(int index) throws ArgumentAccessException; protectednative void setFloatArgument(int index, float throwsArgumentAccessException;     value) protected native bytegetByteArgument(int index) throws ArgumentAccessException; protectednative void setByteArgument(int index, byte throwsArgumentAccessException;     value) protected native ObjectgetObjectArgument(int index) throws ArgumentAccessException; protectednative void setObjectArgument(int index, Object throwsArgumentAccessException;    value) protected native voidprintArgument(int index); protected native Object getClassLoader( );protected static native String getCaller( ); protected static nativeString getCallee( ); protected static native String getMethodName( );protected static native String getSignature( ); protected static nativeboolean pushFilter(InterceptionFilter arg, String filtermethod, Stringfiltersignature, String ic_manager_notify); protected static nativeboolean popFilter( ); protected static native Object[ ] getFilterList(); } // Class InterceptionInfo

Interception Manager Class

The interception manager is implemented in Java and is declared finaland static. The interception manager subclasses the InterceptionInfobase class. It is responsible for controlling and modifying the namespace of the calling entity. The interception manager implements thesecurity policy for the Java environment, regardless of whether thecalling entity is part of an application or part of an applet, i.e.there is no distinction between application and applet. The interceptionmanager defines the boundaries of a security sandbox and establishesgates for communication with the outside of the sandbox.

Since Java has its own memory management, the garbage collection isresponsible for removing obsolete objects and freeing up the memory. Anobject is to be considered obsolete if no reference exists on the Javalevel anymore. Thus, the interception manager has to keep track of everyguard object it created and installed subsequently, otherwise thegarbage collection will remove this object while compactifying thememory. A detailed discussion about of garbage collection was given byT. Lindholm et al,.supra.

The interception manager creates guard objects and decides which one toattach to which method. It also specifies the order in which they willbe called before and/or after the original method.

Interception Filter

The InterceptionFilter class provides the basic functionality requiredby the guard objects. It subclasses the InterceptionInfo class in orderto access the same native C code methods as the interception manager.This class extends the subclassed one with a method to detach itselffrom the original method (the object reference where it is attached to).In the actual implementation, guard objects are executed before theoriginal method is called. Code fragment C6 shows a rudimentary guardobject base class. The defaultCallFilter ( ) method is the method whichis called by default before the object reference is invoked.

Code Fragment C6

public class InterceptionFilter extends InterceptionInfo { protected intunresolve; private protected InterceptionFilter( ) { unresolve = 0; }private protected void defaultCallFilter( ) { throw newICFilterException(“no filter method implemented”); } private protectednative void detachMySelf( ); }

Conclusion

This chapter B presented the key issues of an implementation of theideas expressed in chapter A. The essential functionality of animplementation of the invented security mechanism was described as asubset of the proposed architecture, addressing the principle to controlaccess to system classes representing system resources and to call inarbitrary guard objects.

The modifications done in the Java Virtual Machine were kept at aminimum. The crucial changes were made in the name resolution process,to modify the concrete name space of the calling object, and in themethod invocation process to call guard objects. Security can now beassured for every single method invocation through guard objects or,alternatively and selectively, just once during the name resolvingprocess. Both the interception manager and the guard objects enable aprogrammer to form a variable grained protection mechanism, which can beoptimized in respect of the desired degree of protection as well as froman economical viewpoint.

What is claimed is:
 1. A method for protecting resources against unauthorized access in a data processing system, said resources owned by a called entity and a resource capable of being requested by a calling entity using a symbolic name representing said resource, wherein a totality of symbolic names define a presumed name space for an entity, said distributed data processing system implementing a name resolution process for allocating an object reference to a symbolic name representing said requested resource, said method comprising steps of: providing said name resolution process with a subset of all resources of the system to define a totality of object references reflecting permitted accessible resources capable of being verified by said name resolution process and forming a concrete name space for a called entity; and, permitting said calling entity access only to said concrete name space in said called entity.
 2. The method according to claim 1, wherein the symbolic name includes at least an entity name and a method name.
 3. The method according to claim 1, wherein said step of permitting said calling entity access filter comprises: resolving the symbolic name into an object reference (6) that allows access, in particular immediate access, of the calling entity (7) by invoking a desired method in the called entity (9), thus accessing the desired resource (2 a . . . 2 n).
 4. The method according to claim 1, further comprising the steps of: intercepting a resolved object reference; and attaching a guard object (13) associated with said resolved object reference by substituting a reference to said guard object for the object reference (6), said guard object having functionality for implementing a security policy directed to usage of a resource.
 5. The method according to claim 4, wherein the guard object provides conditional access to the desired method by hiding the object reference (6 b) from the calling entity (7), and controlling the invocation process.
 6. The method according to claim 4, wherein the guard object is called either before and/or after an object reference is used.
 7. The method according to claim 5, wherein the conditional access provided by the guard object is effected at a finer level of breakdown, than a level of breakdown used in the name resolution process.
 8. The method according to claim 1, wherein at least one of the method steps is implemented in an object-oriented manner.
 9. The method according to claim 1, wherein said data processing system is a distributed, networked system.
 10. The method according to claim 1, wherein said resource comprising one or more of: a file or an object that encapsulates data and methods for execution in said system.
 11. An access control system for protecting resources against unauthorized access in a distributed data processing system, said resources owned by a called entity and capable of being requested by a calling entity using a symbolic name representing said resource owned by said called entity, wherein a totality of symbolic names form a presumed name space for an entity, said access control system comprising: name resolution means for resolving a symbolic name by allocating an object reference to a symbolic name representing said requested resource; means for allocating a subset of all resources of the system to define a totality of object references reflecting permitted accessible resources capable of being verified by said name resolution means and forming a concrete name space for an entity; and, means for permitting said calling entity access only to said concrete name space in said called entity.
 12. The access control system according to claim 11, further including means (5 b) for establishing a guard object (13) and for substituting a reference to said guard object for the object reference (6).
 13. The access control system according to claim 11, wherein at least one of the means is implemented in software in an object-oriented manner. 